Subject: Re: Revised Flow Control Proposal

From: [email-masked]
Date: Mon, 14 Mar 94 10:22:55 EST

Bernie,
Great comments.  My responses are embedded ....
Peter

>Peter,
>
>>>ADAPTIVE PACING -
>>>=================
>>>Flags/fields in the short ("information header"), 2nd byte:
>>>- Pacing Request            (PREQ) - 1 bit
>>>- Pacing Response           (PRSP) - 1 bit
>>>- Increment Window Indicator (IWI) - 1 bit
>>>- Halve Window Indicator     (HWI) - 1 bit
>>>- Reset Window Indicator     (RWI) - 1 bit
>>>
>
>Since this will also be set in  DGRM frames this byte will also be
>required in the long header also. Since this is also the case for IPM's
>it make since to use the same byte and definitions in all cases.  By
>what is specified the ADAPTIVE PACING byte is only specified in the
>short header.  This should be doumented for both types.

You're absolutely right.  Since the first 16 bytes of the long header
is the same as the "info msg" header, I think we could just use the
second byte in both for pacing.

>I would also clarify that Pacing is done only on circuits in the
>Connected state,  I take it that  DGRMFRAME was used to imply this.

I actually didn't think about it.  I've always viewed CIRCUIT_ESTABLISHED
as a fine state for a NetBIOS application to do steady state UI frame
data transfer if it never chose to cause a SABME-UA exchange, so my
initial reaction is to do pacing in either CONNECTED or CIRC_ESTAB
states.  I will talk to some other folks here to see if they agree about
the latter state, and I would appreciate hearing your reaction and any
others out there.  This raises the question about how the counters
should be maintained or reset across state transitions, which I did
not specify either.

>The only problem that I see is that while in the connected state the FSM
>specifies that a DLSw can receive either a DGRMFRAME or a DATAFRAME.
>Since they are both the same thing one will be paced and the other will
>not.  If the pacing window was closed and a DATAFRAME is received then
>it does not violate the PACING protocol. I don't know if this creates an
>issue or an implementation benefit.

I will check on what conditions would cause DATAFRAME in CONNECTED
state and get back to you with an opinion on how to handle it.  The
same question applies to CIRCUIT_ESTABLISHED state.

>Error Cases:
>
>One other thing that is missing from the current write up is error
>recovery.  If a pacing widow is exceeded then what is the action to be
>taken.  My take is to send a HALT_DL_NOACK.  I have included a flow
>which is using a  window size of 7.  From the network DLSw receives
>INFOFRAMES.  The IPM is held up by DLSw because  DLC has reported  a
>busy condition.   On receiving the 8th frame DLSw considers the pacing
>widow to be violate and issues a HALT_DL_NOACK to the DLSw peer.

HALT_DL_NOACK sounds like a good choice to me, my only question is
a conformance one:  should we require implementations to do this
error checking in order to conform to the standard, or should it
be a product choice?  I vote for the latter, although it's easy to
argue that everyone should want to protect themselves against a "bad"
other node.

>Flow Chart:
>
>	DLC			   	DLSw			NETWORK
>			  |							|
>			  |	[CONNECTED]			|
>			  |							|
>			  |			      <-:-----INFOFRAME(1)
>			<-:------INFO					|
>			  |			      <-:-----INFOFRAME(2)
>			<-:------INFO					|
>			  |			     <-:-----INFOFRAME(3)
>			<-:------INFO					|
>			  |			      <-:-----INFOFRAME(4)
>			<-:------INFO					|
>			  |			      <-:-----INFOFRAME(5)
>			<-:------INFO					|
>	DLC_DL_BUSY ------:->				|
>			  |			      <-:-----INFOFRAME(6)
>			<-:------INFO					|
>			  |			      <-:-----INFOFRAME(7)
>			<-:------INFO					|
>			  |			      <-:-----INFOFRAME(8)
>			<-:------HALT_DL				|
>			  |							|
>			  |		HALT_DL_NOACK-------:->
>			  |							|
>			  | [HALT_PENDING_NOACK]	|
>			  |				       			|
>			  |			      <-:-----INFOFRAME
>	DLC_DL_HALTED ----:->				|
>			  |				        		|
>			  |	[DISCONNECTED]		|
>			  |				

In your example you say the IPM is held up because of a DLC busy
which doesn't show up until INFOFRAME 5 is received.  This seemed
odd to me because I assumed INFOFRAME 1 was the start of the window,
so the decision to withhold the IPM needed to have been made way
before the DLC busy came in.  Maybe my assumption about the start
of the window was wrong.  Also, is there a particular reason you
showed INFOFRAME coming after the HALT_DL_NOACK?  It seems fine to
expect an I-frame "in flight", I was just wondering if you meant
anything in particular.

---

From: Bernard Brady <[email-masked]>
Date: Mon, 14 Mar 94 13:25:28 EDT

Peter,

>expect an I-frame "in flight", I was just wondering if you meant

I agree that IPM would most likely be sent after the first INFOFRAME
is received but since it's implementation dependent  it might be sent
when some percentage of the window is recieved.  This is what this flow
was trying to show.  This flow should be changed to as follows.

In the case of the extra INFOFRAME it really wasn't needed.